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In zunehmendem Mafie werden 
Microcontroller in Anwendungen 
eingesetzt, die sehr komplex und 
zeitkritisch sind und dazu noch ein 
hohes Mafi an Zuverlassigkeit und 
Fehlertoleranz verlangen, so dafi 
die Anforderungen an Entwick- 
lungs- und Testgerate - insbeson- 
dere an die In-Circuit-Emulatoren 
- immer hoher geschraubt wer- 
den. Doch kdnnen die Emulatoren 
auch im Echtzeitbereich noch mit- 



halten? 



Dieser Beitrag soli anhand ernes Projektes die 
Eigenschaften beschreiben, die fur Embedded* 
Controller-Entwlcklungssysteme heute sehr wun- 
schenswert sind. Beispielhaft herangezogen wird 
hlerzu elne selbst konzipierte Entwicklungsumgebung. 

Aufgabenstellung: Design eines Steuerrechners 

Es sollte ein Steuerrechner mit einem 8032-Prozessor 
fur ein analoges Kassettengerat entwickelt werden, der 
die Ober wachunfl des RAnrilai ifes. die serielle Kornmu - 
nikAtinn tind die Reffejun ff der Band %qschwindigkeit 
simGltan fQr mehrere Kassettenlaufwerke ubernehmen 
sollte. Als Prog rammiersprache war C vorgesehen. 

Die Anforderungen an die Bandgeschwindigkeits- 
Regelung wurden sehr hoch gesteckt: Kurzzeitige 
Geschwindigkeitsabweichungen (Gleichlauf) durften 
maximal 0,07 % betragen, und die Langzeitkonstanz 
(Drift) sollte besser als 0,005 % sein. Die Bandlaufuber- 
wachung mufite Fehlerzustande wie „Bandklemmen M 
und .Bandschlaufe" erkennen und verhinderri, dafi das 
Band besch&digt wird. Eine serielle Kommunikation mit 
einem externen Rechner sollte implementiert werden. 



Die verwendeten Tools 

Eingesetzt wurde ein selbstentwickelter In-Circuit- 
Emulator und ein ebenfalls selbstentwickelter Hard- 
ware-Simulator. In diesen Tools lieBen sich Wunsche 
realisieren, die sich in mehreren Jahren bei der Ent- 
wicklung von „Emb edded-Con tror-Anwendungen her- 
auskristallisiert fiatten in der Codierphase wurde 
hauptsachlich mit dem Simulator gearbeitet. 

Die Implementierung der Firmware im Controller 
und das Testen bzw. Optimieren der Regelungs- und 



Oberwachungsftinktionen erfolgte mit dem In-Circuit- 
Emulator. 



Ohne ^Interrupts" geht es nicht 

Es zeigte siehr dafi alle zeitkritischen Aufgaben in 
Interruptroutinen untergebracht werden mufiten. Die 
Messung der Bandgeschwindigkeit wurde wegen der 
geforderten Mefigenauigkeit mit Hilfe der Capture-Regi- 
ster von Timer 2 vorgenommen. Die Kommunikation, 
die Oberwachung des Bandlaufes sowie der Regel- 
algorithmus mufiten als Interruptroutinen realisiert 
werden; lediglich der Interpreter, der die Kommandos 
der serieUen Schnittstelle bearbeitete, und die Ansteue- 
rung der Stellglieder konnten im Hauptprogramm 
untergebracht werden. Die Regelung selbst wurde als 
Kaskadenregelung mit einer analogen Frequenzvorre- 
gelung realisiert, da der digitate Regelalgorithmus zu 
langsam war, urn den geforderten Gleichlauf zu ermog- 
lichen. Die Regelung wurde schlieBlich verschachtelt 
und die Zeitmefieingange und die Stellausgange gemul- 
tiplext, urn die Ansteuerung mehrerer Laufwerke zu 
ermoglichen. 

Im Verlauf der Projekts stellte sich heraus. dafi die 
Implementierung der Regelung der anspruchsvollste 
Teil der Aufgabe war. 

Was macht das Testen einer digitalen 
Regelung schwierig? 

Damit eine Regelung funktioniert. miissen mehrere 
Dinge gleichzeitig sichergestellt werden: 
O Der Regelalgorithmus muB fehlerfrei sein. 
O Der Fehler bei der Messung der IstgroBe muB gerin- 

ger sein als die zulassige Regelabweichung. 
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O Die Regelparameter miissen abgestimmt sein. 
O Der Regelkreis muB geschlossen sein. 

Module, die zur Regelung gehdren, k6nnen zwar ein- 
zein vorgetestet werden, dennoch laBt sich das dynami- 
sche Verhalten einer Regelung nur in Echtzeit beurtei- 
len. Gerade hier sind leistungsfahige Entwicklungs- 
werkzeuge gefragt, die tiber erweiterte .Echtzeit" -Test- 
moglichkeiten verfiigen. 

Die Interruptroutinen: alctiv im Hintergrund 

Der Steuerrechner sollte neben der Regelung der 
Bandgeschwindigkeit auch die Kontrolle der seriellen 
SchnittsteUe und die Oberwachung des Bandlaufes erle- 
digen. Der Bandlauf laBt sich aber erst dann sinnvoll 
iiberwachen, wenn die Bandgeschwindigkeit korrekt 
eingestellt ist: Deshalb mufiten die Interruptroutinen 
der Regelung zuerst implementiert werden und wfih- 
rend des gesamten Systemtests im Hintergrund aktiv 
bleiben. 

Mit einem Emulator, der die Abarbeitung von Inter- 
ruptroutinen bei stehender Emulation nicht unterstiitzt, 
hatte man diese Anwendung nur noch mit dem Trace 
(Verfolgunsspeicher) testen kdnnen, nachdem die erste 
Intemiptroutine implementiert worden war. Dies wfire 
jedoch eine sehr unkomfortable Ldsung. 

Da der MilcrocontroUer-Emulator auch die Abarbei- 
- tung von Interruptroutinen im Hintergrund unterstiit- 
zen sollte, wurde eine Interrupt-Erkennung und Priori- 
taten-Zuordnung implementiert, die universell mit alien 
8051-Derivaten zusammenarbeitet, bis zu vier Priori- 
tatsebenen berOcksichtigt und vom Anwender keinerlei 
Eingaben erfordert. 

Dadurch ist es moglich, das Programm wie gewohnt 
zu „testen\ d.h. alle zur Verfiigung stehenden Debug- 
Befehle wie ..Single-Step", .Snapshot* oder .Break- 
point" auszufiihren, w&hrend im Hintergrund alle akti- 
ven Interruptroutinen in Echtzeit abgearbeitet werden. 

Eine ungewohnte Programmtest-Strategie 

Daraus ergibt sich eine fiir viele Emulator-Besitzer 
ungewohnte, da von ihren Geraten nicht untersttitzte, 
aber sehr effziente und bequeme Testmethode: Man 
implementiert und prtift die Interruptroutine mit der 
hochsten Priorit&t zuerst Ist diese ^wichtigste" Inter- 
ruptroutine getestet, kommen die Interruptroutinen 
niedrigerer Prioritat an die Reihe, wobei die .wichtig- 
ste" Interruptroutine weiterhin in Echtzeit lauft. Sind 
alle Interruptroutinen getestet und fehlerfrei, kann 
zuletzt bequem das Hauptprogramm gepruft und opti- 
miert werden, wobei aDe Interruptroutinen weiterhin in 
Echtzeit abgearbeitet werden. 

Interaktive Abstimmung der Regelparameter 
bei laufender Regelung 

Wahrend die Regelung in Echtzeit lief, konnten mit 
dem Emulator interaktiv die Parameter geandert wer- 
den. Da die Wirkungen unmittelbar sichtbar waren, lieB 
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sich die Regelung bequem abstimmen. Es wurde ein 
PID-Regler eingesetzt; zunachst als reiner P- (Proportio- 
nal-)Regler implementiert. Der Proportional-Anteil 
wurde anschlieBend so lange verandert, bis das System 
an die Stabilitatsgrenze kam. Die Einstellung der I- 
(Integral-), D- (Differential-) und P- Anteile erfolgte 
zun&chst grob nach EinsteDregeln und konnte interaktiv 
schneU am System optimiert werden. 

Ohne emen leistungsfdhigen Analysator 
geht es nicht 

Es gibt Situationen, in denen ein Entwickler (iber 
einen leistungfahigen Trace- Analysator verfiigen sollte, 
denn komplizierte Soft- oder Hardwarefehler lasseii 
sich meist nur damit aufeptlren. 



Was heiftt „unscharf triggern"? 



Angenommen sai das Bei- 
spiel, in dem rich ein Fehler 
dadurch reigt, dafl eine Flo- 
at-Variable einen fain^h^n 
Wert anxrinunt Hier ist nun 
nicht auf den Wert der Va- 
riablen selbst zu triggern, 
sondexn es gertQgt auf die 
Adresse der Variablen zu 
triggern, was mit jeder 
Breakpoint-Logik einfach 
xndglich sein some. In den 
Trace-Speicher werden alle 



Speicherrugriffe auf die Va- 
riable inclusive Pre-Trace 
geschrieben. Der « Trace- 
Speicher lUt sich nun mit 
oder ohne Software-Unter- 
stdtznncf analysieren und 
somit die fehlarhafte Varia- 
ble suchen. In der zus&tzEch 
zu der Variablen anfge- 
zeichneten Vorgeschichte 
(Pre-Trace) kann die Ursa- 
che des Fehlers lokalisiert 
werden. 



Die meisten Emulatoren verfiigen als Zusatzoption 
tiber einen solchen Analysator. Abhfingig von einem 
Triggersignal werden dabei Bus-Zyklen und Daten von 
Probes in einen Speicher geschrieben, dessen Inhalt 
man zur Programm analyse wieder auslesen kann. 
Bekannte Aufzeichnungsarten sind Pre-, Post- und Cen- 
ter-Trace-Modus. Im Pre-Trace-Modus ist die Aufeeich- 
nung zunichst aktiv, mit dem Triggersignal wird die 
Aufeeichnung gestoppt. Im Speicher stehen die Daten 
zum Zeitpunkt des Triggersignals CTriggerereignis) und 
Daten, die zeitlich vor dem Triggersignal lagen (Pre- 
Trace). Im Post-Trace-Modus wird die Aufzeichnung 
durch das Triggersignal gestartet und bei einer 
bestimmten Abbruchbedingung (z.B. nach 100 Zyklen) 
wieder gestoppt. Im Speicher stehen das Triggerereig- 
nis selbst und Daten, die nach dem Triggersignal aufge- 
treten sind (Post-Trace). Der Center-Trace-Modus stellt 
eine Kombination aus beiden Modi dar. Das Triggersi- 
gnal wird von einer Breakpoint-Logik erzeugt, die der 
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Bifd 1. Mul^le-Cwrter-Troco-Aufeeichhung 
out Source-Code-Ebene: aktives Soorce-U- 
ne-Filt*r, Pre-Trace mit zwei ZyWen, Post- 
Trace mil drei Zyklen r; 



Entwickler programmieren kann. um die Aufzeichnung 
zusteuern. 



-EJV 



1st ^Single Pre-Trace''-Mdc!us ausreichend ? 

Da die Ursachen fQr FeMerzustande zeitlich vor dem 
Auftreten des Fehlerziistandes selbst liegen, ist der Pre- 
Trace-Au£seichnungsmodus nieist das wirkungsuollste 
fMittol zur Fehlersuche. Nachteilig bei dem bekannten 
• Pr0-Trace-Modus ist die Tatsache, daB technisch 
bedingt nur ein Ereignis rait PrerTrace im Speicher 
stehenkann. ~U >-. v»< " Rr '^; i ^ v V t 

- Probleme treten dann au£ wenn auf die Auswirkung 
eines tuil^kannten ^hlersrnicht getriggert werden 
kann- Bei der implenientferten Regelung: muBte man 
beispielsweise die Ursache fiir sporadisch auftretende, 
zu hohe Gleichlaufechwankungen fihden. Wie kann 
man aber auf derartige .AusreiBer* triggern, ohne das 



Gleichlauf-MeBgerat umzubauen und mit einem Trig- 
gerausgang zu versehen ? Ein anderes Beispiel kann ein 
Fehler sein, bei dem eihe Float-Variable einen uner- 
iaubten Wert annimmt* 

Selbst mit einer auBerst leistungsfahigen sequentiel- 
ien Breakpoint-Logik kann in Echtzeit kaum auf den 
Wert einer Float-Variablen getriggert werden. - Doch 
esgibt einen Ausweg. 




Bild 2. Multiple Center-Trece-Aiifzeichnun^ auf Assembler-Ebene: Pro- 
Trace mit xwei Zyklen, Post-Trace mit xwoi Zyklon 

1Q2 



^Multiple Center-Trace" ist die Ldsung 

Mit Hilfe des -Multiple Center-Trace"-Modus ist es 
mdglich, auch .nichttriggerbare Fehler* im Trace-Spei- 
cher aufeuzeichnen und somit zu linden. Doch was 
bedeutet -Multiple Center-Trace"-Modus? 

Zusatzlich zu jedem Triggerereignis konnen ein Pre- 
Trace und ein Post-Trace aufgezeichnet werden. Die 
Lange von Pre- und Post-Trace ist getrennt 
einstellbar und kann zwischen 0 und 512 
Zyklen liegen (BiW I). Ein Speichereintrag, 
der aus Triggerereignis. Pre- und Post-Zy- 
klen bestehfc l£Bt sich dann treffend als 
.Frame" bezeichnen. In Echtzeit und ohne 
Unterbrechung der Trace-Aufeeichnung 
konnen beliebig viele .Frames" in den Trace- 
Speicher aufjgezeichnet werden. Die Anzahl 
der .Frames" hangt von der eingesteUten 
Lange des Pre- und des Post-Trace sowie 
von der Tiefe des Trace-Speichers ab. Im 
32 KWorte tiefen Trace-Speicher des Emula- 
tors lassen sich z. B. 16 KFrames mit jeweils 
einem Pre-Trace-Zyklus aufzeichnen. 

Durch den .Multiple Center Trace"- Mo- 
dus ist man nun bei der Fehlersuche in der 
Lage, .unscharF zu triggern, das heiflt, es ist 
nicht notwendig. auf die exakte Fehlerbedin- 
gung selbst zu triggern, sondern es genugt, 
die Triggerbedingung so zu deGnieren (Bild 
2\ daB wenigstens einer der aufgezeichne- 
ten Frames den Fehler enthalL 
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BiW 3. Details ium A»iiys«rtorst«h« 



• Durch „Rlter** den Trace-Speicher optimal nutzen 

•I' Gerade beim Hochsprachen-Trace kann es vorkom- 
men, daB der Trace-Speicher schlecht genutzt wird. Es 
ist namlich durchaus keine Seltenheit, wenn eine Hoch- 
sprachen-Zeile mehr als 1000 Assemblerbefehle ent- 
halt. In -BTtter ungefilterten Aufzeichnung wurden so 
nicht einmal 32 QueDcode-Zeilen in einen 32 KWorte 
tiefen Trace-Speicher passen! 

Im hier beschriebenen Emulator wurden deshalb 
dem Trace-Speicher verschiedene Filter vorgeschaltet 
Durch Setzen dieser Filter kann der Entwickler errei- 
chen. daB nur Daten. die ihn interessieren, aufgezeich- 
net werden; Dies erhdht einerseits die Obersichtlichkeit 
der Aufeeichnung, andererseits spart dieses Verfahren 
Speicherplatz. so daB Langzeittests uberhaupt erst 
moglich werden. Durch Ausnfltzen der Filter und der 
sehr leistungsfahigen sequentiellen Breakpoint-Logik 
kann die Aufzeichnungsdauer extrem verlangert wer- 
den (z.B. fiber Nacht). Dies ist hilfreich bei Langzeit- 
tests, wenn also ein Fehler nur selten auftaucht Eine 
solche Situation wfire z.B. ein Stack-Oberlauf nach Auf- 
ruf einer Interruptroutine. die ihrerseits eine sehr spei- 
cherintensive Hauptprogrammroutine unterbricht 

Folgende Filter, die voneinander unabhSngig und fQr 
Pre- und Post-Trace aktiviert werden k6nnen, wurden 
implementiert: 

O Unterprogramm-Filter: Aufgezeichnet wird nur der 
Unterprogrammaufiruf; das Unterprogramm selbst 
jedoch nicht. Dadurch kann erreiqht werden, daB ein 
bereits getestetes Unterprogramm nicht mehr aufge- 
zeichnet wird. Dies erhdht die Lesbarkeit einer 
Trace-Aufeeichnung wesentlich. 

O Interrupt-Filter: Das Filter verhindert, daB Interrupt- 
anforderungen die Trace-Aufzeichnung des zu 
testenden Programmteils unterbrechen. Dieses Filter 
funktioniert im wesentlichen genauso wie das Unter- 
programm-Filter. 
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O Source-Line-Filter: Dieses Filter wurde spe- 
ziell fur Anwendungen in Hochsprache im- 
plementiert. Aufgezeichnet werden nur die- 
jenigen Befehle, die einer Hochsprachenzeile 
enteprechen. Dies fiihrt zu einer auBerst 
komprimierten und Trace-Speicher sparen- 
den AtrfeeichnungvonC-Programmen. Selbst- 
verstfindlich erfolgt die Ahzeige des Trace- 
Speichers auch auf Source-Code-Ebene. 
O Befehls-Filter: Nur bestimmte Gruppen von 
Befehlen (z.B. alle Sprungbefehle) werden 
aufgezeichnet Dies ist z.B. fQr folgende Test- 
situation interessant: Ein Unterprogramm 
soil getestet werden, wobei wichtig ist, wel- 
che Routinen zuvor aufgerufen wurden. Da- 
zu aktiviert man im Pre-Trace das Befehls- 
Filter und zeichnet nur alle Unterprogramm- 
aufrufe (Befehl .call ..^ auf. Im Post-Trace ist das 
FUter inaktiv; das komplette Unterprogramm wird 
aufgezeichnet. 
O Zyklus-Filter: Die CPUs der Intel-8051-Famffie fuh- 
ren pro Befehl bis zu acht Speicherzugriffe durch. Fur 
einen GroBteil aDer Testanwendungen genQgt jedoch 
der erste Speicherzugrifi: da mit diesein dermiszu- 
ffihrende Befehl festgelegt wird und die weiteren 
Opcodes (z.B. RAM-Adressen) spfiter aus dem 
bekannten Programm rekonstraiert werden kSnnen. 
1st dieses FUter aktiviert, so werden nur die ersten 
Speicherzugriflfe imd alle Zugriffe auf ein externes 
RAM aufgezeichnet ^ 
O Frei programmierbares Filter: Spezielle Programm- 
teUe kSnnen mit einem Cursor markiert und somit 
zur Aufzeichnung freigegeben werden. Dieses FUter 
laBt sich sehr flexibel einsetzen (siehe auch Bild 3). 



S^fan tklit ttuaWt* Bektroiecrv 
r* on der TU MOnehen und Est soft 
1986 bei der Hfmo ftcht-Moon^. 
ion GmbH in der Ertfwfckkjrtg folia 
Ne benoefuflkhbelrefcteroinB*- 
wfcWwngslobor, in dem u.a der 



hvQrcvft-Emuialor 
entwfcfcelt wurde. 
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sfeflten In-Circuit- Emulators war er mafi- 
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